The present invention relates to data communication over a network, more particularly to a segmentation method used for transmission of large data packets.
Recent advances in hardware and communication technologies have introduced the era of mobile computing over wired and wireless links. The proliferation of powerful notebook computers and wireless communications promises to provide users with network access at any time and in any location over the Internet. This continuous connectivity will allow users to be quickly notified of changing events and provide them with the resources necessary to respond to them even when in transit.
In mobile networks, such as that proposed by Internet Engineering Task Force (IETF), a mobile host is allowed to roam freely on the Internet while still maintaining the same IP address. In such systems, data transfer delay requirements are critical and transmissions must support efficient transport. These requirements are even more critical for real-time applications, such as voice or video. The Internet community has a well-developed and mature set of layered transport and network protocols, which are quite successful in offering to end-users both connection-oriented transport protocols, such as Transport Control Protocol (TCP), and connectionless transport protocols, such as User Datagram Protocol (UDP), over connectionless network services, such as Internet Protocol (IP). Many popular network applications have been built directly on top of the TCP and UDP over the past decade. These have helped these Internet services and protocols to become widely-spread de facto standards.
Interconnection layer protocols and interfaces there between are defined to provide specifications for communication between a process or program being executed on one host computer""s operating system and another process or program running on another computer. Transmission control protocol/internet protocol (TCP/IP) are two protocols that are part of a protocol suite or family of protocols layered and designed to connect computer systems that use different operating systems and network technologies.
FIG. 1(a) illustrates conceptual layers for TCP/IP as well as the format of objects passed between adjacent protocol layers. TCP/IP is a four layer protocol suite (the hardware layer is not counted) which facilitates interconnection on the same or different networks, and in certain networks such as the Internet, is a requirement for interoperability. TCP, which is a transport layer protocol, is used to access applications on other hosts, and IP permits identification of source and destination addresses for communication between hosts on the same or different networks. The fundamental internetwork service consists of a packet delivery system, and the internetwork protocol (IP) defines that delivery mechanism, i.e., the basic unit of data transfer.
The basic data transfer unit is often called a xe2x80x9cdatagramxe2x80x9d as is well known in the art and is divided into header and data areas, as shown in FIG. 1(b). The header contains source and destination addresses and a type field that identifies the contents of the datagram. For example, a UDP header consists of a UDP source port and UDP destination port. A UDP message length field indicates the number of octets in a UDP datagram, and a UDP check sum provides an optional checksum of UDP and some parts of the IP header. The IP protocol only specifies the header format including the source and destination IP addresses; it does not specify the format of the data area.
The IP protocol also performs a routing function by choosing a path over which data will be sent. Using special procedure called routing protocols, routers exchange information among themselves and the hosts to which they are connected. This allows them to build tables, called routing tables, which are used to select a path for any given packet from a source to a destination. Although there can be more than one router along the path, each router makes only an individual forwarding decision as to which is the next host or router, i.e., the next network hop. This method is called hop-by-hop routing and is distinguished from end-to-end protocol that is implemented at transport through application layers.
Forwarding decisions at each node are based on fields within the IP header and based on entries in the nodes""s IP routing table. FIG. 1(c) illustrates a standard IP header which consists of a number of predefined fields. Some of the fields in IP header remain constant throughout the path between the source and destination. For example, fields SOURCE IP ADDRESS and DESTINATION IP ADDRESS, which, in IPv4, contain the thirty-two bit IP addresses of the datagram sender and intended recipient, remain unchanged throughout the path. As each node makes its forwarding decision, other IP header fields, may change according to a constant parameter, for example, sequentially, or they may change in a more unpredictable way.
In order to carry data that has real-time properties, a protocol known as Real-time Transport Protocol (RTP) is defined for providing end-to-end delivery services, such as interactive audio and video, with a growing interest in using RTP as one step to achieve interoperability among different implementations of network audio/video applications. The delivery services include payload type identification, sequence numbering, time stamping and delivery monitoring. Although RTP may be used with a number of suitable underlying network or transport protocols, such as TCP, applications typically run RTP on top of UDP to make use of its multiplexing and checksum services, with both RTP and UDP protocols contributing parts of the transport protocol functionality. For Internet environment, of course, the underlying network service or layer for such session and transport layers is the IP.
As stated above, over end-to-end connections, each of the RTP, UDP, or IP has an overhead associated with corresponding headers, with header overhead for RTP, UDP, and IPv4 being 12 bytes, 8 bytes and 20 bytes, respectively, for a total of 40 bytes of combined header overhead. Occasionally, this 40-byte combined overhead is larger than the actual payload itself. Because a large transmission bandwidth is required to accommodate such a large overhead, especially over low speed lines, such as dial-up modems at 14.4 or 28.8 kb/s, a header compression technique has been proposed as an IETF Standard Protocol by Casener et al. titled xe2x80x9cCompressing IP/UDP/RTP Headers for Low-Speed Serial Links,xe2x80x9d February 1999. This document is identified by IETF as Request for Comment 2508 (hereinafter referred to as RFC 2508) and is hereby incorporated by reference. Similar to TCP header compression, the proposed IP/UDP/RTP header compression in RFC 2508 relies partly on the assumption that some of the bytes in headers remain constant over the life of the connection. Moreover, differential coding on changing header fields is used to reduce their size and to eliminate the changing fields entirely for common cases by calculating the changes from a previous packet length, as indicated by the underlying link-level protocol.
The header compression of RFC 2508 offers a reduction in the combined compression of IP, UDP and RTP headers to two bytes for packets when UDP checksums is not sent, or four bytes when UDP checksums is sent. Although the proposed compression may be applied to the RTP header alone on an end-to-end basis, the compression of the combination of IP, UDP and RTP headers on a link-by-link basis is preferred because the resulting header overhead is approximately the same (2-4 bytes) in either case, and because compressing on a link-by-link basis provides better performance due to lower delay and loss rate.
The use of IP/UDP/RTP compression over a particular link is a function of the link-layer protocol, which defines negotiation rules for reliable transfer of data packets between two nodes. One known link layer protocol is the Point-to-Point Protocol (PPP) which provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: a method for encapsulating multi-protocol datagrams, a Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection, and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
In an IETF proposed protocol identified as RFC 1990 by Sklower et al., titled xe2x80x9cThe PPP Multilink Protocol (MP),xe2x80x9d August 1996 (hereinafter referred to as RFC 1990), which is hereby incorporated by reference, a multilink protocol is disclosed that based on an LCP option negotiation permits a system to indicate to its peer that it is capable of combining multiple physical links into a xe2x80x9cbundle.xe2x80x9d The system offering the option is capable of combining multiple independent links between a fixed pair of systems, providing a virtual link with greater bandwidth than any of the constituent members.
More specifically, the multilink operation disclosed in RFC 1990 is modeled as a virtual PPP link-layer entity wherein packets received over different physical link-layer entities are identified as belonging to a separate PPP network protocol, the Multi-link Protocol. The packets are recombined and sequenced according to information present in a Multilink header. Under the Multilink Protocol of RFC 1990, the PPP multilink fragments are encapsulated using a protocol identifier. Following the protocol identifier is a two or four byte header containing a sequence number, and two one bit fields indicating that the fragment begins a packet or terminates a packet. Using the Multilink header, the system can then receive upper layer protocol data units (PDU) in a fragmented form, reassemble the fragments back into the original PDU for processing. All packets received over the links identified as belonging to the Multilink arrangement are presented to the same network-layer protocol processing unit, whether they have the Multilink headers or not.
In IP networks, a packet size may become quiet large. According to RFC 2508, a segmentation scheme over the link layer may be used in conjunction with the proposed header compression to allow small, real-time packets to interrupt large, presumably non-real-time packets in order to reduce delay, particularly for providing interactive services, for example, audio services, where minimizing the end-to-end delay is critical. Without giving specific details, RFC 2508 propose segmentation to be handled by a separate layer. However, RFC 2508 requires the implementation of segmentation and compression to be performed in such a way that the compression could be used by itself in situations where segmentation is necessary. Under this arrangement, the compression scheme of RFC 2508 is to be applied locally on the two ends of a link independent of any other mechanisms, except for the requirements that the link layer provides packet type codes, a packet length indication, and error detection. However, supporting segmentation by a separate network layer adds to the complexity and overhead of the system.
Conventionally, when IP headers are not compressed, the data packets are forwarded without being reassembled at each node. However, when compressed header format is used, the data packets need to be reassembled at each node in order to retrieve destination information for correctly forwarding the data packets along to the next node. In some IP networks that have a limited physical link bandwidth, for example, those in a cellular access network that use radio frequency channels, the per hop delay imposed by large packets could become significant, if data packets are reassembled at each node. If the number of nodes (i.e., hops or routers) within the network is also large, the aggregated delay caused by large packets may become significantly large as well. With limited physical link bandwidth, the large per-node delay may significantly degrade offering real-time audio and video services. Therefore, there exists a need for a segmentation scheme that reduces per-node delay due to large packets without adding undue complexity and system overhead.
The present invention reduces per-node delay by assembling datagram segments at the destination, as opposed to at each intervening node along the path from the source to the destination. As such, each node quickly forwards a received datagram segments without reassembly. Once at the destination, the datagram segments are reassembled, instead of being reassembled multiple times at the intervening nodes.
Briefly, according to the invention, a data packet is communicated between a source node and a destination node having a destination address by being segmented into a plurality of datagram segments such that each datagram segment has a corresponding header. The datagram segments are forwarded through the intervening nodes between the source and destination nodes, based on unique segmentation context identification (CID) values inserted at headers of each of the datagram segments as the datagram segments are forwarded through the intervening nodes. Under the present invention, an inserted CID value at an intervening node correlates the destination address with a corresponding output port address, until the datagram segments are received at the destination node. The datagram segments are then reassembled at the destination node, without being reassembled at each intervening node. Preferably, sequence information are inserted into the headers of each datagram segment at the source node to be reassembled at the destination node, based on the sequence information.
According to another aspect, a data packet having a header and an associated data portion is segmented into a plurality of datagram segments which are transferred in accordance with a header compression and link layer switching technique of the invention. Each datagram segment has a corresponding header and data portion. The header has one of two formats: a full header and a compressed header. Both header formats include a unique CID value. In addition to CID value, the full header format also including at least one IP address. The compressed header may also include information corresponding to header fields that change according to a constant parameter or those that change unpredictably.
Under the present invention, the link layer switching is based on the CID value. Instead of forwarding datagram segments based on the IP address, they are forwarded based on the CID value. In this way, the segmentation technique of the present invention allows the datagram segments to be communicated over the nodes without being reassembled at each node. As stated above, the datagram segments are reassembled at the destination node.
According to some of the more detailed features of the invention, when a datagram segment is received, a determination is made as to whether the received header has a full or compressed format. If it has a full format, a routing table is analyzed to identify an outgoing port that corresponds to the IP address received with the full header. The identified outgoing port number and the incoming CID value are stored in a CID table. The received datagram segment is then forwarded on the outgoing port with a compressed header that has an outgoing CID value that replaces the incoming CID value. If the received header is compressed, its incoming CID value is analyzed based on the CID table. The corresponding datagram segment is forwarded on an output port that corresponds to the incoming CID value. Before being forwarded, the incoming CID value in the compressed header is replaced by an outgoing CID value corresponding to the output port.